Fixed failure paths not setting socket to -1 consistently, changed close to lwip_close to resolve assert #6942
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fixed issue with ssl_client->socket being closed without being consistently set to -1. Changed close to lwip_close to be consistent with lwip_socket, resolved issue with long term assert after 4+ days (assert failed: lock_release_generic locks.c:186).
|
|
|
Thanks @Anx2k :) Will be part of 2.0.4 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of Change
Ran into an issue where an assert would be cause from WebClientSecure stopping after extended uptime (typically happened after 4 days, and usually in conjunction with heavy SD card access). Assert would manifest like this:
assert failed: lock_release_generic locks.c:186 (h)
0x400843d9: panic_abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp_system/panic.c line 402
0x4008eb9d: esp_system_abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp_system/esp_system.c line 128
0x4009432d: __assert_func at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/newlib/assert.c line 85
0x40085df3: lock_release_generic at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/newlib/locks.c line 181
0x40085ee9: _lock_release at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/newlib/locks.c line 207
0x4014184c: vfs_fat_close at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/fatfs/vfs/vfs_fat.c line 513
0x40118c73: esp_vfs_close at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/vfs/vfs.c line 498
0x400faef5: WiFiClientSecure::stop() at C:\Users\Mark\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.3\libraries\WiFiClientSecure\src\WiFiClientSecure.cpp line 93
Looked like it was two issues; one less common, but not all of the failure cases of start_ssl_client would set ssl_client->socket to -1, as it does with the first failure cases as well as in stop_ssl_socket. Second was more specific to the above assert, and that was changing close() to lwip_close(). With these two changes it's back to weeks of uptime, only restarting when I manually take action.
Tests scenarios
M5StickC, several custom ESP32-WROOM-32D boards, Espressif DevKitC board. The test software writes data to an SD card at the rate of 1 sample (typically ~80 chars) every 5 seconds, and sends data to a cloud HTTPS server once every 5 minutes. Previous versions on 1.0.6 had uptimes in months+, but switching to 2.0.3 dropped uptime to hours or a day or two at best. With these changes I've had it reliably run for 2+ weeks (haven't had a device up for longer yet).
Related links
None (to my knowledge).